Dynamic rate control

ABSTRACT

Dynamic rate control can be implemented in a television-based entertainment environment when forwarding coded data. Real-time information flows are encoded, transcoded, compressed, etc. into data streams that may be forwarded to other components within an apparatus or to other apparatuses across a network. In a described implementation, a bitcount accumulation of a data stream is monitored in multiple overlapping windows. The data stream is compared to a data limit in each window of the multiple overlapping windows to determine whether an expected bitcount accumulation has been exceeded. The data stream is modified responsive to the comparison(s). For example, if the bitcount accumulations in each window exceed the expected bit accumulations at the corresponding relative positions of each window, then the bit rate of the data stream can be modified by reducing bit rate consumption.

TECHNICAL FIELD

This disclosure relates in general to real-time rate control and inparticular, by way of example but not limitation, to implementingdynamic rate control under finite bandwidth constraints in real-time.

BACKGROUND

Television-based entertainment systems are expanding the programming andservices that they offer. In addition to television program content suchas that found on broadcast and traditional cable networks, televisionservice providers are adding interactive services, features, andapplications. Such content and additional information are downloadedover a television-based network for display, use, and/or storage onclient-side set-top boxes or similar devices. These downloads includeaudio and/or video information that are transmitted in real-time. Toreduce the amount of data that is streamed, the information is typicallycompressed from a first size to a second smaller size. Because thestreaming occurs in real-time, the information flow is compressedon-the-fly without knowing the ultimate data rate level and/or amount ofdata that will be produced and therefore streamed.

Regardless of whether the information to be transmitted is intended tobe sent over a network or stored in a memory (or both), there is afinite amount of bandwidth available for the compressed data. Forexample, a given network has a maximum transmission capacity at which itis designed to operate, often on both an individual user level and on atotal composite level. Audio and video information may be compressed byencoding it using any of many available approaches and standards, suchas a Moving Pictures Expert Group(MPEG)-based standard. The encodingreduces the bandwidth needed to transmit or store the resulting data.However, the degree to which encoding compresses information variesdepending on the information itself. For example, some informationcompresses to one-fourth of its previous size while other informationcompresses to only one-half of its previous size, even using the sameencoding parameters.

A transmission or storage medium's bandwidth limit(s) provide a guide asto what encoding parameters should be selected for compressing audio andvideo information to achieve a desired data rate that meets the medium'sbandwidth limits. Unfortunately, because the same encoding parameterscompress different information to differing degrees, it can be difficultif not impossible to accurately predict the ultimate bandwidth limitsthat will be met using a given set of encoding parameters on a real-timeinformation flow.

In fact, there are two primary options for selecting encoding parametersin concert with adhering to bandwidth limits of a given transmission orstorage medium. First, aggressive encoding parameters may be selected tosignificantly reduce the size of the resulting compressed data stream toensure that any bandwidth limits are satisfied, but presentation qualitysuffers when the overly-compressed data is decompressed and the originalaudio and video information is presented. Second, conservative encodingparameters may be selected so that both compression and consequentialquality reductions are minimized, but then data may be dropped orotherwise lost if medium bandwidth limits are exceeded. For example, ifthe memory storage bandwidth limit is exceeded prior to completion of areal-time data streaming event, then any un-stored data is lost.

Accordingly, for television-based entertainment systems, there is a needfor schemes and techniques to enable the real-time compression of audioand video information that will meet bandwidth constraints while notunduly reducing the resulting presentation quality of the audio andvideo information after decompression.

SUMMARY

Dynamic rate control can be implemented in a television-basedentertainment environment when encoding, transcoding, or compressingdata. Real-time information flows are encoded, transcoded, compressed,etc. into data streams that may be forwarded to other components withinan apparatus or to other apparatuses across a network. In a describedimplementation, a bitcount accumulation of a data stream is monitored inmultiple overlapping windows. The data stream is compared to a datalimit in each window of the multiple overlapping windows to determinewhether an expected bitcount accumulation has been exceeded. The datastream is modified responsive to the comparison(s). For example, if thebitcount accumulations in each window exceed the expected bitaccumulations at the corresponding relative positions of each window,then the bit rate of the data stream can be modified by reducing bitrate consumption.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference likeand/or corresponding aspects, features, and components.

FIG. 1 illustrates an exemplary television system architecture in whichthe systems and methods for dynamic rate control can be implemented.

FIG. 2 is a graph that illustrates an exemplary data stream on whichdynamic rate control may be implemented.

FIG. 3 illustrates exemplary apparatuses for a television-basedentertainment system in which dynamic rate control units may beimplemented.

FIG. 4 is a flow diagram that illustrates an exemplary dynamic ratecontrol algorithm.

FIG. 5A is a graph that illustrates an exemplary approach for generatinga window_level_modifier.

FIGS. 5B and 5C are graphs that illustrate another exemplary approachfor generating a window_level_modifier.

FIG. 6 illustrates an exemplary set of multiple overlapping time_windowsin order to determine multiple window_level_control_parameters.

FIG. 7A illustrates an exemplary dynamic rate control unit from acomponent perspective.

FIG. 7B illustrates an exemplary dynamic rate control unit from afunctional perspective.

FIG. 8 is a flow diagram that illustrates an exemplary method fordynamically controlling a data stream.

FIG. 9 is a flow diagram that illustrates an exemplary method fordynamically controlling a data rate.

DETAILED DESCRIPTION

The following discussion is directed to television-based entertainmentsystems, such as interactive TV networks, cable/satellite networks, andWeb-enabled TV networks. Client devices in such systems range fromfull-resource clients with substantial memory and processing resources,such as TV-enabled personal computers and TV recorders equipped withhard-disks, to low-resource clients with limited memory and/orprocessing resources, such as traditional set-top boxes. However,dynamic rate control as described herein may additionally be used inother environments such as streaming (e.g., over the Internet);real-time compression and decompression; general encoding, decoding, andtranscoding; and so forth. While aspects of the described systems andmethods can be used in any of these environments and for any types ofclient devices, they are described primarily in the context of thefollowing exemplary environment.

Exemplary System Architecture

FIG. 1 illustrates an exemplary television entertainment system 100 thatis an architecture in which dynamic rate control may be implemented.System 100 facilitates distribution of content and other information tomultiple viewers. System 100 includes one or more content providers 102,zero, one or more other information providers 104, a contentdistribution system 106, and one or more data-consuming (client) devices108(1), 108(2), . . . , 108(N) coupled to content distribution system106 via a network 110.

Content provider 102 includes a content server 112 and stored content114, such as movies, television programs, commercials, music, andsimilar audio and/or video content. Content server 112 controlsdistribution of stored content 114 from content provider 102 to contentdistribution system 106. Additionally, content server 112 may controldistribution of live content (e.g., content that was not previouslystored, such as live feeds) and/or content stored at other locations tocontent distribution system 106. Content server 112 may engage indynamic rate control during the distribution of content from storedcontent 114, live content, and/or other content.

Other information provider 104 includes other information database 116and other information server 118. Other information database 116 storesinformation that may be provided to client devices 108. Such informationincludes software modules, files, images, text, executable programs,gaming or other interactive information, and so forth. The informationmay also include content, especially content of an irregular,one-of-a-kind, or similar nature, or content from smaller independentproviders. Part or all of the information from other informationdatabase 116 may be better enjoyed or utilized when provided to clientdevices 108 in real-time, such as streamed audio and/or visualinformation, interactive games, and so forth. Other information server118 processes the other information from other information database 116prior to distribution to generate one or more files that are optimizedfor, or at least capable of, transmission to content distribution system106. This processing may include dynamic rate control.

Content distribution system 106 includes a transceiver 128, one or morecontent processors 130, and one or more other information processors132. Transceiver 128 can alternatively be a broadcast transmitter ifbidirectional communication is not required. Transceiver 128 transmits(e.g., broadcasts) signals, such as cable/satellite television signals,across network 110. Network 110 can include a cable television network,RF, microwave, satellite, and/or data network, such as the Internet, andmay also include wired or wireless media using any transmission formator protocol. Additionally, network 110 can be any type of network(including a broadcast network), using any type of network topology andany network communication protocol, and can be represented or otherwiseimplemented as a combination of two or more networks.

Content processor 130 processes the content received from contentprovider 102 prior to transmitting the content across network 110.Similarly, other information processor 132 processes the otherinformation that is received from other information provider 104 priorto transmission of the other information across network 110. Aparticular content processor 130 may encode, or otherwise process, thereceived content into a format that is understood by the multiple clientdevices 108(1), 108(2), . . . , 108(N) that are coupled to network 110.Content processor 130 and/or other information processor 132 may engagein dynamic rate control when distributing content and other information,respectively, to the client devices 108. Although FIG. 1 shows a singlecontent provider 102, a single other information provider 104, and asingle content distribution system 106, the exemplary system 100 caninclude any number of content providers and/or other informationproviders coupled to any number of content distribution systems. Thus,content distribution system 106, content provider 102, and/or otherinformation provider 104 are individually or jointly representative of aheadend service that provides content and other information to multiplesubscribers.

Client devices 108 can be implemented in a number of ways. For example,a client device 108(1) receives content and other information from asatellite-based transmitter via a satellite dish 134. Client device108(1) is also referred to as a set-top box or a satellite receivingdevice. Client device 108(1) is coupled to a television 136(1) forpresenting the content and other information (e.g., audio information,video information, and/or data information) that are received by theclient device 108(1), as well as for presenting a graphical userinterface. A particular client device 108 can be coupled to any numberof televisions 136 and/or similar devices that can be implemented todisplay or otherwise render content. Similarly, any number of clientdevices 108 can be coupled to a single television 136.

Client device 108(2) is also coupled to receive content and otherinformation from network 110 and to provide the received content andother information to associated television 136(2). Client device 108(N)is an example of a combination television 138 and integrated set-top box140. In this example, the various components and functionality of theset-top box are incorporated into the television, rather than using twoseparate devices. Set-top box 140 that is integrated into television 138can receive signals (e.g., broadcast signals) via a satellite dish(similar to satellite dish 134) and/or directly via network 110. Inalternate implementations, client devices 108 may receive signals viathe Internet or any other network, especially those network mediums thatare broadcast-capable. As is further described below, client devices 108may also engage in dynamic rate control when forwarding information(whether content information or other information) to memory storage,other client devices, and so forth.

The exemplary system 100 also includes streamed information from othernetworks provider 142, which may provide information such as informationstreamed over the Internet, information streamed directly from aprovider of the information, and so forth. Streamed information fromother networks provider 142 may be accessible over network 110 (i.e., anetwork that also provides content information and other informationfrom content distribution system 106). Alternatively, streamedinformation from other networks provider 142 may be accessible over adifferent network, including a wide area network (WAN), the Internet, apublic or private telecommunications network, and so forth.

Dynamic Rate Control of a Data Stream

FIG. 2 is a graph 200 that illustrates an exemplary data stream 202 onwhich dynamic rate control may be implemented. Data stream 202 is acompressed version of an information flow such as content informationfrom stored content 114 (of FIG. 1), other information from otherinformation database 116, or streamed information from streamedinformation from other networks provider 142. When information is to beforwarded from one location or component to another location orcomponent, it may be advantageous to compress the information into datathat consumes less bandwidth than the original information. Thecompression can be effectuated using any of many available or customizedtechniques. Many such techniques comport with one or more standardspromulgated by the Moving Picture Experts Group (MPEG), but othertechniques may also be used.

An entire information unit such as a movie or video clip may becompressed and then forwarded. On the other hand, only part of theentire information unit may be compressed before forwarding commences.When the forwarding begins prior to compression of the entireinformation unit, the information flow may be considered as beingstreamed in real-time. As a result, the ultimate data size or data rateof the entire information unit is unknown when the forwarding commencesand as the forwarding is occurring. This presents no problem if thebandwidth that maybe consumed for forwarding is unlimited. However,bandwidth is typically finite. Consequently, in such situationsaccommodations may be made to limit the bandwidth consumed whenforwarding the compressed information flow as a data stream.

The bandwidth may be limited to comply with a maximum transmission rate,a total available memory storage, and so forth. Because the totalbandwidth for the entire information unit cannot be limited as the datais being streamed, individual portion or portions may be limited toensure that the total data rate or data size does not exceed the totalavailable or assigned bandwidth. In other words, the data transmittedduring a predetermined unit of time may be limited.

Graph 200 plots time along the abscissa axis from zero (0) to apredetermined unit of time that is denoted as “time-slot”. Graph 200plots bitcount along the ordinate axis from zero (0) to a predeterminedtotal accumulation of bits denoted as “target_bitcount”. An informationflow that is to be forwarded in real-time is compressed into data stream202. Limits, which may be soft and/or flexible limits, are placed ondata stream 202 according to the target_bitcount. In other words, inevery elapsed time unit that is approximately equal to the time_slot,data stream 202 is expected to have forwarded/accumulated/consumed abitcount that is approximately equal to the target_bitcount. A dashedline 204 extends diagonally from a first point (0,0) to a second point(time_slot, target_bitcount). This dashed line 204 represents anapproximate expected bitcount of data stream 202 at any particular pointin time. Noted on graph 200 are (i) a particular point 206 along datastream 202 and (ii) a current_time and a current_bitcount thatcorrespond thereto.

As can be seen from graph 200, data stream 202 is initially below dashedline 204. During this time, data stream 202 is not consuming as muchbandwidth as has been allotted. While there is no need to change thecompression level during this initial period with respect to ensuringthat data stream 202 does not exceed the target_bitcount limit by theend of the time_slot, it may be beneficial to reduce the compressionlevel in order to reduce information loss from the compression. Reducingthe compression level usually improves the resulting presentationquality of the information after decompression. When data stream 202 isabove dashed line 204, data stream 202 has/is consuming more than theallotted number of bits as of that time/position in the time_slot. Inorder to ensure that all of the information that is allotted to beforwarded during the given time_slot has some available bandwidth, evenas the time nears the end of the time_slot, the compression level isincreased so as to reduce the bit consumption of the resulting bitstream 202.

In order to keep the presentation quality after decompression relativelyconstant, data stream 202 is kept relatively near dashed line 204. Thiseffectively reduces the likelihood that very few (or no) bits are leftas data stream 202 approaches the end of the time_slot. In other words,situations where data stream 202 reaches a bitcount accumulation oftarget bitcount well before the end of the time_slot should generally beavoided. U.S. Nonprovisional Patent Application Ser. No. 09/880,243entitled “Non-Compensated Transcoding of a Video Stream”, includesdescription directed to avoiding these situations. U.S. NonprovisionalPatent Application Ser. No. 09/880,243, having a filing date of Jun. 13,2001, is hereby incorporated by reference in its entirety herein.Monitoring and adjusting data stream 202 during any given time_slot mayenable all of the information allotted to that given time_slot to beforwarded at a relatively constant quality level. Unfortunately,especially given that different segments (e.g., time_slots or windows)of a single information unit may be compressed to differing degrees,there may be human-perceptible presentation quality fluctuations betweentime_slots. Data stream 202 may, however, be monitored and consequentlyadjusted over multiple overlapping time_slots or windows, while stillstreaming the original information flow in real-time, as is describedherein.

FIG. 3 illustrates exemplary apparatuses 302 and 108 for atelevision-based entertainment system 300 in which dynamic rate controlunits 304 may be implemented. A headend 302 is in communication with adestination 306. Headend 302 may correspond to one or more of contentprovider 102 (of FIG. 1), other information provider 104, contentdistribution system 106, streamed information from other networksprovider 142, and so forth. Destination 306 may correspond to a home,business, or other location that includes at least one client device108. Headend 302 sends content information, streamed information, andother information towards client device 108A over network 110. Clientdevice 108A receives the content information, streamed information, andother information via network 110.

Each of headend 302 and client device 108A includes one or more dynamicrate control units 304. Dynamic rate control units 304 may be formedfrom general processor(s) and memory component(s) of the respectiveheadend 302 and client device 108A. Alternatively, specific processor(s)and/or memory component(s) may be used to implement dynamic rate controlunits 304. For example, an application specific integrated circuit(ASIC) may be created and utilized as dynamic rate control units 304. Inany event, dynamic rate control units 304 may operate to dynamicallycontrol the bit rate of data streams that are being forwarded inreal-time.

At headend 302, dynamic rate control unit 304HE performs real-time ratecontrol prior to and simultaneously with the forwarding of a coded(e.g., encoded, transcoded, compressed, etc.) data stream to an outputcomponent 308. In this case, dynamic rate control unit 304HE iseffectively (en)coding real-time information into a data stream. Outputcomponent 308 may correspond to transceiver 128 (of FIG. 1), atransmitter, or any general output device suitable for interoperabilitywith network 110. The data stream is forwarded over network 110 fromoutput component 308. In the implementation of FIG. 3, a cabletransmission medium 110(C) and a satellite transmission medium 110(S)are shown. Other transmission mediums may alternatively be used torealize network 110 as is described above with reference to FIG. 1. Thedata stream is forwarded from output component 308 over cabletransmission medium 110(C) and/or satellite transmission medium 110(S).

The data stream is received at destination 306 using an input component310 of client device 108A via cable transmission medium 110(C) and/orsatellite transmission medium 110(S). Input component 310 may correspondto any device suitable for interoperability with network 110 such as acable/satellite network interface, a TCP/IP network interface, a generalreceiver or transceiver, and so forth. Input component 310 may providethe encoded data stream to one or more decoders (not shown) and/or oneor more tuners for subsequent processing, display, and/or storage. Inputcomponent 310 may also provide the encoded data stream to dynamic ratecontrol unit 304CD.

Dynamic rate control unit 304CD receives a decoded data stream from adecoder (not shown) or an encoded data stream directly from inputcomponent 310. When dynamic rate control unit 304CD receives an encodeddata stream, dynamic rate control unit 304CD is effectively transcodingthe encoded data stream into another, transcoded data stream that iscompressed further and therefore consumes still fewer bits. Dynamic ratecontrol unit 304CD may forward the transcoded data stream to memorystorage 312 and/or to local output component 314. Memory storage 312 iscapable of storing the data stream. Memory storage 312 may beimplemented with one or more memory components, examples of whichinclude a random access memory (RAM), a disk drive, another mass storagecomponent, a non-volatile solid-state memory (e.g., ROM, Flash, EPROM,EEPROM, etc.), and so forth. It should be understood that dynamic ratecontrol unit 304CD may alternatively forward an encoded data stream tomemory storage 312 and/or to local output component 314 when dynamicrate control unit 304CD is operating on non-encoded/decoded data.

Local output component 314 is capable of transmitting the transcoded (orencoded) data stream over a local network 316 that extends over all orpart of destination 306. Local output component 314 and local network316 may operate in accordance with any wired or wireless networkprotocol, examples of which include a local area network (LAN), a TCP/IPbased network, a Bluetooth® network, an IEEE 802.11b-based network, andso forth. The transcoded (or encoded) data stream is received via localnetwork 316 at one or more client devices 108B, . . . 108Z. Clientdevices 108B, . . . 108Z each include a local input component (notshown) for interfacing with local network 316 and one or more decodersfor decoding the transcoded (or encoded) data stream. Client devices108B, . . . 108Z may also each include a dynamic rate control unit 304CDfor forwarding a data stream to a memory storage located thereat or toanother client device. Client devices 108B, . . . 108Z are capable ofproviding the original, non-coded information flow to an associatedtelevision 136 or 138 for presentation thereon.

Exemplary Dynamic Rate Control Implementations

An exemplary dynamic rate control algorithm is described using the tenterms (numbered (1)-(10)) in Table 1 below. The numbers in brackets inTable 1 correspond to element reference numbers from FIG. 4, which isdirected to a flow diagram of the exemplary algorithm and is describedbelow. (1) A “data_chunk” is a logical subset of data. In an MPEG-basedimplementation, a data_chunk may be macroblock, a slice, a picture, agroup of pictures (GOP), and so forth. (2) A “time_window” is a set ofcontiguous data chunks that extend for a duration of a time_slot. (3) A“time_slot” is the time length of a time_window. For example, atime_slot may be equivalent to 30 pictures. (4) A “current_time” is apoint in time of a time_slot and corresponds to a particular data_chunk.(5) A “target_bitcount” is the total expected bitcount accumulation overa time_window. For example, a target_bitcount of 4,000,000 bits for atime_slot of 30 pictures results in a 4 Mb/s data stream, assuming 30pictures are presented each second. (6) A “current_bitcount” is a numberof bits accumulated at and by a particular point during a time_window.

(7) A “window_level_control_parameter” (WLCP) is used to control thenumber of bits consumed by a data_chunk. In other words, the WLCP is abit rate control parameter that affects the resulting bit rate of aninformation flow that is coded into a compressed data stream. The WLCPmay be a scalar, a vector, a matrix parameter, and so forth. In anMPEG2-based implementation, for example, the WLCP may comprise the“quant matrix”, the “quant_scale”, or both. (8) A“window_level_modifier” (WLM) is a parameter that is used to modify theWLCP on a per-data_chunk basis. (9) “Multiple overlapping time_windows”(MOTWs) are multiple time_windows that overlap such that each instant intime and each data_chunk is included in more than one time_window. Eachtime_window of the MOTWs includes its own target_bitcount,current_bitcount, WLM, WLCP, and mechanism(s) for adjusting the WLCP.(10) A “top_level_control_parameter” (TLCP) is a parameter that cancontrol the bit rate. The TLCP results at least from combining thecontributions of multiple WLCPs (from corresponding MOTWs) that areassociated with the current time instant.

TABLE 1 Terms used in exemplary dynamic rate control algorithm. TERM[FIG. 4 Element No.] ALGORITHMIC INTERPRETATION (1) data_chunk (1)logical subset of data (2) time_window (2) set of contiguous data_chunksthat extend for a duration of a time_slot (3) time_slot [404] (3) lengthof time for a time_window (4) current_time [402] (4) point in timeduring a time_slot (5) target_bitcount [408] (5) total bitcountaccumulation expected over a time_window (6) current_bitcount [406] (6)number of bits accumulated at a point in time during a time_window (7)window_level_control_parameter (7) controls the number of bits (WLCP)[420] consumed by a data_chunk (8) window_level_modifer (WLM) (8)parameter to modify the WLCP on [416] a per-chunk basis (9) multipleoverlapping time_windows (9) multiple time_windows that (MOTWs) [418]overlap such that each instant in time and each data_chunk is includedin more than one time_window (10) top level_control_parameter (10)parameter for controlling bit rate (TLCP) [430] that results at leastfrom combining the contributions of multiple WLCPs from correspondingMOTWs

FIG. 4 is a flow diagram 400 that illustrates an exemplary dynamic ratecontrol algorithm. Both qualitative and quantitative perspectives onflow diagram 400 are presented herein. A qualitative overview of theexemplary dynamic rate control algorithm is provided next. Acurrent_time 402, a time_slot 404, a current_bitcount 406, and atarget_bitcount 408 are determined in accordance with a data stream andtime_window as shown in FIG. 2. Current_time 402 and time_slot 404 areused to produce a time-related ratio 410. Current_bitcount 406 andtarget_bitcount 408 are used to produce a bitcount-related ratio 412.Time-related ratio 410 and bitcount-related ratio 412 are used togenerate WLM 416. Generating a WLM 416 is described further below withreference to FIGS. 5A, 5B, and 5C. An original WLCP 414 (e.g., animmediately previous WLCP) and WLM 416 are used to determine a new WLCP420.

New WLCP 420 is determined with respect to an individual (butoverlapping) time window. However, (other) multiple overlapping timewindows (MOTWS) are used to produce multiple (new) WLCPs 418 for eachgiven instant of time. While the absolute overall time instant and datastream point are the same, each time_window of all of the MOTWs has itsown relative current_time 402 and current_bitcount 406. Multiple (new)WLCPs 418 and new WLCP 420 are combined into a combination WLCP 424 torepresent all of the time_windows of the MOTWs. An exemplary set ofMOTWs are described further below with reference to FIG. 6. One or moreprevious TLCPs 422 and combination WLCP 424, along with weightingcoefficients 426 and a weighting coefficient 428, are used to calculatea current TLCP 430. Exemplary calculation methodologies are alsopresented below. Current TLCP 430 is used to set or adjust the bit rateof the data stream that results from an information flow being encoded,transcoded, or compressed.

A more quantitative view and a detailed description of the exemplarydynamic rate control algorithm is provided next. With reference now toFIGS. 2 and 4, the time_window of the graph 200 defines the temporallength of the window as time_slot 404 and the total expectedaccumulation of bits as target_bitcount 408. Each point along datastream 202, such as particular point 206, is associated with acurrent_time 402 and a current_bitcount 406. The ratio of current_time402 to time_slot 404 forms time-related ratio 410. The ratio ofcurrent_bitcount 406 to target_bitcount 408 forms bitcount-related ratio412. One or both of ratios 410 and 412 are used to generate WLM 416.

WLM 416 may be generated using any of many possible mechanisms. Asalluded to above, U.S. Nonprovisional patent application Ser. No.09/880,243, entitled “Non-Compensated Transcoding of a Video Stream”,outlines one mechanism for generating WLM 416. The following second andthird mechanisms are additional alternatives. These two mechanisms aredescribed algebraically as:WLM=1/[(1−current_time/time_slot)*(1−current_bitcount/target_bitcount)]^p;and  [1]WLM=1/[(1−current_time/time_slot)+(1−current_bitcount/target_bitcount)]^p,  [2]

-   -   where “p” is a user selectable parameter.

If the user desires that the rate control algorithm respond relativelyrapidly to changes in the input, a large value of “p” (e.g., p>1) may bechosen. For a more damped response, relatively small values of “p”(e.g., p<=1) may be chosen.

In general under these two second and third mechanisms, WLM 416increases as current_bitcount 406 approaches target_bitcount 408. Andfor the same ratio 412 of current_bitcount/target_bitcount, WLM 416becomes larger as current_time 402 approaches the end of the time_window(i.e., time=time_slot 404). Exemplary fourth and fifth mechanisms aredescribed below with reference to FIG. 5A and FIGS. 5B-C, respectively.

FIG. 5A is a graph 530 that illustrates a fourth exemplary mechanism forgenerating a WLM 416. This fourth mechanism is a zone-based mechanism inwhich the magnitude and positive/negative value of the WLM is determinedresponsive to the zone in which data stream 202 is located at theparticular point in question. The graph 530 includes six zones: D−, S−,M−, M+, S+, and D+. The lettered zones correspond to a dramatic (D)change, a significant (S) change, and a minor (M) change. Thepositive/negative denotation indicates whether the WLM is positive ornegative. For example, if a particular point along data stream 202 islocated in the S− zone, then the WLM for that particular point in thetime_window under consideration corresponds to the numeric valueassigned to the S− zone. The numeric values assigned to the six zonesmay be determined empirically. As indicated by the dramatic (D),significant (S), and minor (M) designations, the absolute numeric valuesincrease from the minor (M) zone to the significant (S) zone and fromthe significant (S) zone to the dramatic (D) zone. In alternativeimplementations, more or fewer than six zones may be utilized.

The positively-denoted zones above dashed line 204 represent that theWLM is positive; hence, the WLM will increase the WLCP (in thisimplementation as described further below). The negatively-denoted zonesbelow the dashed line 204 represent that the WLM is negative; hence, theWLM will decrease the WLCP. Thus, when a particular point of data stream202 is located in the M+ zone, the WLCP is increased by an amount M oran amount proportional to M. The increased WLCP, if applied directly tothe quantization of the information flow that produces data stream 202,results in a coarser quantization (e.g., a coarser encoding ortranscoding). The coarser quantization causes a reduced bit rateconsumption that “drives” data stream 202 back towards dashed line 204.As is explained further below, an increased WLCP decreases the bit rateconsumption when information is being compressed according to an MPEGstandard for example. However, other standards may be employed in whichan increased WLCP increases bit rate consumption. In such instances, thepositive/negative denotations (and corresponding values) of the zones ofgraph 530 are swapped.

FIGS. 5B and 5C are graphs 560 and 590 that illustrate a fifth exemplarymechanism for generating a WLM 416. This fifth mechanism is afunction-based mechanism. The bitcount deviation of data stream 202 fromdashed line 204 is mapped to a WLM value. The function may bearithmetic, geometric, exponential, and so forth. For example, thefunction may square the bitcount deviation to map to a WLM so that thegreater the bitcount deviation of data stream 202 from dashed line 204,the greater the WLM and the faster the data stream 202 may bere-directed to the expected bitcount accumulation as represented bydashed line 204. A specific exemplary function is shown in FIGS. 5B and5C.

The graph 560 indicates five continuous zones A, B, C, G, and H. Incontrast to the discrete zones of the fourth exemplary mechanism asillustrated in the graph 530 (of FIG. 5A), the five zones of the graph560 map to continuously variable values of WLM. Graph 590 plots bitcountdeviation along the abscissa axis versus WLM values along the ordinateaxis. The five continuous zones A, B, C, G, and H from graph 560 arealso noted along the bitcount deviation axis. A function 592 maps thebitcount deviation of data stream 202 to the WLM values. This function592 may be implemented computationally, as a tabular data structure in amemory, and so forth.

When the bitcount deviation is slightly negative (e.g., when data stream202 is located below dashed line 204, as in zone G), the WLM is zero sothat the WLCP is unchanged. When the bitcount deviation is more negative(e.g., located in zone H), the WLM is negative and increases in thenegative direction at a predetermined rate. When the bitcount deviationis slightly positive (e.g., located in zone A), the WLM is positive andincreases at a first predetermined rate. As the bitcount deviationbecomes more positive (e.g., located in zone B), the WLM becomes morepositive and increases at a second, higher predetermined rate.Eventually, so as to prevent the WLM from becoming too large and theWLCP from changing to quickly, the WLM value becomes saturated even asthe bitcount deviation increases (e.g., when the bitcount deviation islocated in zone C). Any one or more of these five exemplary mechanismsmay be used in order to generate a WLM 416.

Continuing again wither reference to flow diagram 400 of FIG. 4, a newWLCP 420 is determined by using WLM 416 and an original (e.g., animmediately previous) WLCP 414. In an exemplary MPEG implementation, theWLCP may correspond to the quant_scale, the quant_matrix, or both. TheWLCP determination mechanisms described below may be used for eitherquantization parameter or both. The quant_scale is a parameter within anMPEG stream that enables the changing of the quantization scale of eachmacroblock. The quant_matrix is a matrix parameter in an MPEG streamthat is constant for all macroblocks for the duration of a picture. Eachelement of this matrix can be changed using any of the exemplary WLCPdetermination functions f1 defined below.

Given a WLM on a per-chunk basis, the new_quant_scale for eachmacroblock is determined as a function (f1) of this WLM together withthe original_quant_scale of the macroblock. Other MPEG parameters may beinvolved in the function as well. In general,new_quant_scale=f1 (WLM, original_quant_scale, optionallyother_parameters).

Five (5) exemplary functions (f1) for determining a WLCP 420 in anMPEG-based implementation are presented below:f1=original_quant_scale+WLM;  (1)f1=original_quant_scale * WLM;  (2)f1=mbtype==INTRA? original_quant_scale:original_quant_scale+WLM;  (3)f1=frametype==I_TYPE? original_quant_scale:original_quant_scale+WLM;and  (4)f1=original_quant_scale+WLM*(2*gopsize−current_position_in_(—)gop)/(2*gopsize).  (5)Function (3) depends on the type of MPEG macroblock. Function (4)depends on the type of MPEG frame. Function (5) depends on the size ofthe group of pictures (GOP) and the current position in the GOP.

Determining new WLCP 420 therefore involves original WLCP 414 and WLM416. When using an MPEG-based compression/coding approach, new WLCP 420may correspond to new_quant_scale (in the f1 functions above) andoriginal WLCP 414 may correspond to original_quant_scale. For othercompression/coding standards and schemes, the applicable bit ratecontrol parameter or parameters thereof may be substituted for thequant_scale/quant_matrix parameters of MPEG. The applicable bit ratecontrol parameter(s) of other standards and schemes may thereforecorrespond to the WLCP of the algorithm of flow diagram 400 (of FIG. 4).

The algorithmic aspects 402-420 generally apply to a single time_window,such as the one that is illustrated in FIG. 2. A particular point 206corresponds to a current_time 402 and a current_bitcount 406. WLM 416 isgenerated from this particular point along data stream 202. Applying WLM416 to original WLCP 414 determines a new WLCP 420. This new WLCP 420serves to govern the bit rate of data stream 202 relative to an expectedbitcount accumulation (e.g., as indicated by the dashed line 204) and atotal expected bitcount accumulation as designated by target bitcount408 at time_slot 404. The WLCP 420 thus governs, or limits, the bitcountaccumulation of data stream 202 in terms of a single time_window. Thiscan cause the bit-rate-limiting feature of such an algorithm to, forexample, reduce presentation quality within a first time_windowunnecessarily because the bit rate in a succeeding time_window will belower in any event due to information therein that is more easilycompressed. Furthermore, modifying data stream 202 from the perspectiveof a single, artificially imposed time_window can create a beatingeffect in the information as presented aurally, visually, etc. afterdecoding/decompression.

This beating effect is a human-perceptible change in presentationquality between data that was compressed at a first factor in a firsttime_window and immediately succeeding data that was compressed at asecond factor in a second, immediately succeeding time_window. Thiscompression factor differential, and the resulting beating effects,arise because of higher quantization towards the end of time_windowsfollowed by lower quantization at the beginning of time_windows. Tomitigate this beating effect, multiple overlapping time_windows areemployed.

FIG. 6 illustrates an exemplary set 600 of multiple overlappingtime_windows (MOTWs) in order to determine multiplewindow_level_control_parameters (WLCPs). In the MOTW set 600, bitcountis illustrated as increasing in the upward direction, and time isillustrated as elapsing in the rightward direction. The MOTW set 600includes three time_windows 602(1), 602(2), and 602(3). Although onlythree time_windows 602 are shown as overlapping any given instant oftime and/or position along data stream 202 in the MOTW set 600, two,four, five, or more time_windows may alternatively be used. Also,although each time_window 602 of “n” time_windows in the MOTW set 600 isshown as overlapping the immediately previous time_window 602 by“(n−1)/n” of a time_window width, other overlapping distributions mayalternatively be used.

Data stream 202 is illustrated as crossing through all three illustratedtime_windows 602 as it reaches an intermediate or a final bitcount forthe data stream as generated by the compression/coding standard that isbeing applied to the information flow that is to be forwarded. Eachparticular point along data stream 202, such as particular point 604 attime=N, is simultaneously located in three overlapping time_windows 602.Each time_window 602 is used to independently generate a WLM 416, andeach of these WLMs 416 is used to generate a (new) WLCP 420 from arespective (original) WLCP 414. New WLCPs 420 from each time_window ofthe MOTW set 600 are then combined.

Because the multiple time_windows 602 are overlapping, for any giventime instant, the relative “current_time=N” is different in eachrespective time_window 602. The current_bitcount, also being relativefor each time_window 602, is likewise different in each respectivetime_window 602, even for the same particular point 604 along datastream 202. Although the target_bitcount and the time_slot values maydiffer between and among time_windows 602, they are at leastapproximately equal in the MOTW set 600 implementation as illustrated inFIG. 6.

The use of MOTW sets provides the ability to view the same particulardata point of data stream 202 at different phases, thus mitigating thebeating effect. More specifically, because the same bitcount is viewedthrough MOTWs, each instant of absolute time falls in different relativetime locations and positions of the different overlapping time_windows.This mitigates the problem of drastic presentation quality reduction atthe end of a time_window because (at any instant of absolute time) therewill be other time_windows that will be operating at the beginning, nearthe beginning, at the middle, etc. of their time slots.

Continuing now with reference to FIG. 4, new WLCP 420 is thereforedetermined from one time_window of a MOTW set. Similarly, multiple newWLCPs 418 are determined from the other time_windows of the MOTW set. Toproduce combination WLCP 424 from the MOTW set, new WLCP 420 is combinedwith each WLCP of multiple new WLCPs 418. The WLCP 420 and the multipleWLCPs 418 (jointly termed the “contributing WLCPs”) may be combinedusing any of many possible approaches. For example, the contributingWLCPs may be averaged to combine them into combination WLCP 424. Theaverage may comprise the mean of the contributing WLCPs, the median ofthe contributing WLCPs, and so forth. Each individual WLCP of thecontributing WLCPs may also be individually weighted.

Combination WLCP 424 may be used as (current)top_level_control_parameter (TLCP) 430. Current TLCP 430 is used as thebit rate control parameter (e.g. to set a quantization level) for thecompression/coding standard or approach that is being used. In an MPEGimplementation, for example, current TLCP 430 corresponds to thequant_scale, the quant_matrix, or both. Using combination WLCP 424 ascurrent TLCP 430 smoothes quantization levels from one time window tothe next. However, the quantization level can still change toodramatically and/or be subject to spurious deviations in theinformation-flow-to-be forwarded such that changes in the presentationquality after decompression are perceivable to the human eye or ear. Toavoid this, (previous) TLCPs 422 may be used to calculate current TLCP430; this can minimize or reduce the likelihood that quantization levelschange too quickly by incorporating a history of TLCPs.

In other words, the TLCP to be used in quantizing the information flowinto data stream 202 may be modified by using previously calculatedTLCPs. Current TLCP 430 may be calculated from combination WLCP 424,previous TLCPs 422, weighting coefficients 426, and weightingcoefficient 428. This calculation may be accomplished, for example, viaan autoregressive model such as:TLCP(n)=Σ_(k=n−1, n−2, . . . ,n−m) a _(n)(k) TLCP(k)+a _(n)(n)C(n),where “C(n)” is the result of combining the contributing WLCPs toproduce combination WLCP 424 for the current time instant. The parameter“m” is set based on the desired memory length for the current TLCP 430calculation. The historical memory length aspect of the current TLCP 430calculation is increased as the value of “m” is increased. The parameter“a_(n)(k)” is represented in flow diagram 400 by weighting coefficients426, and the parameter “a_(n)(n)” is represented by weightingcoefficient 428. In an exemplary implementation, a_(n)(k) is set equalto 0.9 for k=n−1, and zero for smaller values of k, and a_(n)(n) is setequal to 0.1. In general, the greater the value of a_(n)(k) relative tothat of a_(n)(n), the slower the quantization rate changes because thereis greater emphasis placed on the historical (i.e., previous) TLCPvalues 422. An exemplary simplification of the term a_(n)(k) is to havea dependence only on the difference between n and k, i.e.a_(n)(k)=a(n−k).

The algorithm of flow diagram 400 (of FIG. 4) thus provides a mechanismfor dynamically providing rate control for an information flow that isbeing compressed/coded into a data stream. The mechanism limits orgoverns the total bit accumulation of the resulting data stream whileminimizing or reducing perceptible beating effects. Dynamic rate controlunits 304 (of FIG. 3) may implement, optionally in conjunction withother components of headend 302 and client device 108, the algorithm offlow diagram 400.

Exemplary Dynamic Rate Control Units

FIG. 7A illustrates an exemplary dynamic rate control unit 304 from acomponent perspective. Dynamic rate control unit 304 includes one ormore processors 702 and one or more memories 704. Processor 702 iscapable of processing various instructions to control the operation ofdynamic rate control unit 304 and to communicate with other componentsand/or other electronic/computing devices. Memory 704 can be implementedwith one or more memory components, examples of which include a randomaccess memory (RAM), a disk drive or other mass storage component, anon-volatile memory (e.g., ROM, Flash, EPROM, EEPROM, etc.), and soforth. While any single type of memory or combination of memory types ispossible, memory 704 most likely includes at least (i) a RAM forprocessing and (ii) a mass storage or non-volatile memory forlonger-term storage. Memory 704 is adapted to store various instructionsand/or information such as operating system and/or configurationinformation, stream-able data, and so forth.

Specifically, memory 704 stores computer-executable instructions,relevant data structures, and/or any other information for implementingthe algorithm of flow diagram 400 (of FIG. 4) as denoted by dynamic ratecontrol algorithm 706. Dynamic rate control unit 304 may be realized inany of many possible manners. For example, processor 702 and memory 704may be integrated together on one or more dedicated chips (e.g., one ormore ASICs). Alternatively, processor 702 and memory 704 may be sharedacross one or more other tasks being performed by headend 302 or clientdevice 108. In fact, dynamic rate control algorithm 706 may be stored ingeneral purpose memory and executed on general purpose processor(s) (notshown separately) of headend 302 or client device 108 using, forexample, a multi-tasking and memory sharing scheme.

It should be noted that client devices 108 can include a range ofprocessing and memory capabilities, and may include more or fewer typesof memory components than those enumerated above. For example,full-resource clients 108 can be implemented with substantial memory andprocessing resources, including a disk drive or similar mass storagemedium. Low-resource clients, however, may have limited processing andmemory capabilities, such as a limited amount of RAM, no disk drive,limited processing capabilities, and so forth. Furthermore, clientdevices 108 may include a decoder to decode a broadcast video signal,such as an NTSC, PAL, SECAM or other TV system video signal.

FIG. 7B illustrates an exemplary dynamic rate control unit 304 from afunctional perspective. Dynamic rate control unit 304 includes six (6)functional blocks. Each functional block may be implemented as an IC orpart thereof, as a logical module operable by processor(s) inconjunction with memory or memories, as one or more computer-executableinstructions, and so forth. The latter two examples may be stored in acomputer-accessible memory (e.g., as part of dynamic rate controlalgorithm 706 (of FIG. 7A)). The functional blocks 752-762 are describedbelow with reference to specific aspects 402-430 of the algorithm offlow diagram 400 (of FIG. 4). However, it should be understood that thefunctions performed by blocks 752-762 may overlap across multipleaspects of flow diagram 400 or may only perform a portion of one or moreof such aspects.

A time and bitcount monitor block 752 performs aspects 402 and 406 offlow diagram 400 by monitoring and being capable of providingcurrent_time 402 and current_bitcount 406. Time and bitcount monitorblock 752 may also perform aspects 404 and 408 by recording and beingcapable of providing time_slot 404 and target_bitcount 408. A WLMgenerator block 754 performs aspects 410, 412, and 416 of flow diagram400 after receiving parameters from time and bitcount monitor block 752.WLM generator block 754 (along with the other functional blocks of FIG.7B) may also implement any of the alternatives described above withreference to the various aspects of flow diagram 400. For example, WLMgenerator block 754 may generate WLM 416 based upon (i) the position inthe time_window, (ii) the current_bitcount thereat, and (iii) theposition in the GOP.

A WLCP determiner block 756 performs aspect 420 (new WLCP) inconjunction with aspect 414 (original WLCP), as is described above withreference to FIG. 4, using a WLM from WLM generator block 754. A TLCPhistory storage block 758 stores previous TLCPs (for aspect 422) in amemory of dynamic rate control 304, such as memory 704. The number ofprevious TLCPs stored in TLCP history storage block 758 corresponds tothe parameter “m” as described above with respect to the autoregressivemodel implementation. A WLCPs combiner block 760 performs aspect 424 by,for example, receiving multiple WLCPs of multiple overlappingtime_windows from WLCP determiner block 756 and averaging the multipleWLCPs. A TLCP calculator block 762, when present, performs aspects 426,428, and 430 to calculate a current TLCP from previous TLCPs and acombination WLCP as received from TLCP history storage block 758 andWLCPs combiner block 760, respectively.

Methods for Dynamic Rate Control

Dynamic rate control may be described in the general context ofcomputer-executable instructions. Generally, computer-executableinstructions include routines, programs, objects, components, datastructures, and the like that perform particular functions or implementparticular abstract data types. Dynamic rate control may also bepracticed in distributed computing environments where functions areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment,computer-executable instructions may be located in both local and remotecomputer storage media.

The methods of FIGS. 8 and 9 are illustrated in flow diagrams dividedinto multiple method blocks. However, the order in which the methods aredescribed is not intended to be construed as a limitation, and anynumber of the described method blocks can be combined in any order toimplement one or more methods for dynamic rate control. Furthermore,although the methods are described below with reference to televisionentertainment environments 100 and 300 and the algorithm of flow diagram400 where applicable, the methods can be implemented in any suitablehardware, software, firmware, or combination thereof and using suitablemathematical alternatives.

FIG. 8 is a flow diagram 800 that illustrates an exemplary method fordynamically controlling a data stream. Flow diagram 800 includes threemethod blocks 802, 804, and 806 that may be performed by dynamic ratecontrol units 304. At block 802, a data stream is monitored in multipleoverlapping windows. For example, a bit accumulation from the datastream in each of the multiple overlapping windows may be monitored todetermine how fast the data stream is consuming bits. At block 804, thedata stream is compared to a data limit in each window of the multipleoverlapping windows. For example, at a given particular absolute pointof the data stream that is located at varying relative positions in eachwindow of the multiple overlapping windows, the bit accumulation at theparticular point is compared to an expected bit accumulation at thecorresponding relative position in each window of the multipleoverlapping windows.

At block 806, the data stream is modified responsive to the comparisons.For example, if the bit accumulations in each window exceed the expectedbit accumulations at the corresponding relative positions, then the datastream can be modified by reducing bit rate consumption. The bit rateconsumption may be reduced by increasing the quantization coarseness ofthe compression/coding being applied to the underlying information flow.If, on the other hand, the bit accumulations in each window are belowthe expected bit accumulations at the corresponding relative positions,then the data stream can be modified by increasing bit rate consumption.Various compromises, interpolations, and/or averages may be employedwhen some bit accumulations are above and some bit s accumulations arebelow the expected bit accumulations at the corresponding relativepositions in the multiple overlapping windows. Some examples of whichare provided above with reference to flow diagram 400 (of FIG. 4). Forinstance, greater (or lesser) weight may be given to the modificationrecommendation originating from a window in which the given particularpoint is located at a relative position that is near the end of thatwindow.

FIG. 9 is a flow diagram 900 that illustrates an exemplary method fordynamically controlling a data rate. Flow diagram 900 includes eightmethod blocks that illustrate a dynamic rate control wherecoding/compressing starts at a first bit rate and is changed to a secondbit rate. The method of flow diagram 900 may be performed at dynamicrate control units 304. At block 902, an information flow is coded(e.g., encoded, transcoded, compressed, etc.) using a first bit rateparameter. Using an MPEG coding process, for example, the bit rateparameter may correspond to a quant_scale, a quant_matrix, or both. Withrespect to flow diagram 400, the bit rate parameter may correspond to afirst (current) TLCP 430. At block 904, the bit accumulation of the bitstream that results from coding the information flow is monitored overtime. In effect, the bit consumption of the bit stream is tracked atvarious times (as the flow diagram 900 is repeated during real-timeuse). These various times are notable as corresponding to the currentbitcount accumulation.

The variance between the actual bit accumulation and an expected bitaccumulation is determined at block 906. The expected bit accumulationis predetermined for each time window based on bandwidth limits. A bitrate change recommendation may be determined from the variance. This bitrate change recommendation may correspond to a WLM of aspect 416 of flowdiagram 400. At block 908, a bit rate recommendation for the currenttime window is determined from the variance (e.g., using a respectivebit rate change recommendation). This determination may ultimatelycorrespond to aspect 420. At decision block 910, it is determinedwhether there are still additional time windows for consideration. Ifso, then flow diagram 900 continues at block 904 to repeat blocks904-908 for another time window. If not, then flow diagram 900 continueswith block 912. In other words, if all of the relevant overlapping timewindows have been analyzed to secure a bit rate recommendationtherefrom, then the method can proceed to combine them. It should beunderstood that all or part of the “repeating” of blocks 904-908 may beoccurring substantially simultaneously.

At block 912, the bit rate recommendations are combined. The bit raterecommendations for multiple time windows as determined in repeatedperformances of block 908 are thus combined. This combination maycorrespond to aspect 424 of flow diagram 400. A second bit rateparameter is determined based on the combination at block 914. Thesecond bit rate parameter may correspond to a second (current) TLCP 430.As such, the second bit rate parameter may be determined (i) directlyfrom the combination of bit rate recommendations or (ii) using the firstbit rate parameter (optionally along with other previous bit rateparameters) and the combination of bit rate recommendations in anautoregressive or other (e.g., mathematical) model. The latter optionmay correspond to aspects 422, 426, and 428 of algorithm 400. After thesecond bit rate parameter is determined, coding is effectuated using thesecond bit rate parameter at block 916. Flow diagram 900 may be repeatedas the information flow/data stream is coded into the bit streamaccording to the current bit rate parameter. The bit stream may also becontemporaneously being forwarded from dynamic rate control unit 304 tooutput component 308, local output component 314, memory storage 312,and so forth.

CONCLUSION

Although systems and methods have been described in language specific tostructural features and/or methods, it is to be understood that theinvention defined in the appended claims is not necessarily limited tothe specific features or methods described. Rather, the specificfeatures and methods are disclosed as exemplary forms of implementingthe claimed invention.

1. A method for providing real-time rate control, comprising: tracking acurrent bitcount in a time window of a plurality of time windows; notinga current time in the time window; generating a window level modifierbased on the current time and the current bitcount in the time window;determining a new window level control parameter for the time windowbased on the window level modifier; repeating the actions of tracking,noting, generating, and determining for each other time window of theplurality of time windows to produce a plurality of new window levelcontrol parameters, wherein each time window of the plurality of timewindows overlaps at least one other time window of the plurality of timewindows; combining each new window level control parameters at a windowlevel control parameter combiner, the window level control parametercombiner adapted to combine the new window level control parameter foreach respective time window of the plurality of time windows to producea combined window level control parameter, wherein the window levelcontrol parameter combiner is further adapted to combine the new windowlevel control parameters for each respective time window of theplurality of time windows using an average of the new window levelcontrol parameters for each respective time window of the plurality oftime windows; and calculating a top level control parameter based on thenew window level control parameter and the plurality of new window levelcontrol parameters.
 2. The method as recited in claim 1, wherein theaction of tracking a current bitcount comprises accumulating bits from adata stream during the time window.
 3. The method as recited in claim 1,wherein the action of noting a current time comprises noting a time thatcorresponds to the current bitcount in the time window.
 4. The method asrecited in claim 1, wherein the action of generating a window levelmodifier comprises: ascertaining a time-related ratio between thecurrent time and a total time for a time slot that corresponds to thetime window; ascertaining a bitcount-related ratio between the currentbitcount and a target bitcount for a total expected bitcountaccumulation that corresponds to the time window; and generating thewindow level modifier responsive to the time-related ratio and thebitcount-related ratio.
 5. The method as recited in claim 1, wherein theaction of generating a window level modifier comprises generating thewindow level modifier such that the window level modifier is greater thefurther the current bitcount is above an expected bitcount.
 6. Themethod as recited in claim 1, wherein the action of generating a windowlevel modifier comprises generating the window level modifier such thatthe window level modifier is greater the closer the current time is to atotal time for a time slot that corresponds to the time window.
 7. Themethod as recited in claim I, wherein the action of generating a windowlevel modifier comprises generating the window level modifier such thatthe window level modifier is greater the closer the current bitcount isto a target bitcount of a total expected bitcount accumulation thatcorresponds to the time window.
 8. The method as recited in claim 1,wherein the action of generating a window level modifier comprisesgenerating the window level modifier using at least one of a zone-basedmechanism or a function-based mechanism.
 9. The method as recited inclaim 1, wherein the action of determining a new window level controlparameter comprises determining the new window level control parameterfor the time window based on the window level modifier and an originalwindow level control parameter.
 10. The method as recited in claim 9,wherein the action of determining the new window level control parametercomprises adding the window level modifier to the original window levelcontrol parameter.
 11. The method as recited in claim 9, wherein theaction of determining the new window level control parameter comprisesmultiplying the window level modifier and the original window levelcontrol parameter.
 12. The method as recited in claim 1, wherein theaction of determining a new window level control parameter comprisesdetermining the new window level control parameter responsive to a groupof pictures (GOP)-related parameter.
 13. The method as recited in claim1, wherein the action of determining a new window level controlparameter comprises determining the new window level control parameterresponsive to at least one of a macroblock type or a frame type.
 14. Themethod as recited in claim 1, wherein the new window level controlparameter comprises at least one of a quantization scale or aquantization matrix.
 15. The method as recited in claim 14, wherein themethod is used in conjunction with a Moving Pictures Expert Group(MPEG)—compliant coding/compressing technique.
 16. The method as recitedin claim 1, wherein the plurality of time windows comprise “n” totaltime windows, and the actions of tracking, noting, generating, anddetermining are repeated “n-1” times in the action of repeating; andwherein the plurality of time windows are arranged such that eachsubsequent time window overlaps a previous time window by an “(n-1)/n”portion of a time window length.
 17. The method as recited in claim 1,wherein the action of calculating a top level control parametercomprises calculating the top level control parameter based on the newwindow level control parameter, the plurality of new window levelcontrol parameters, and a plurality of previous top level controlparameters.
 18. The method as recited in claim 1, wherein the action ofcalculating a top level control parameter comprises calculating the toplevel control parameter responsive to a combination of the new windowlevel control parameter and the plurality of new window level controlparameters.
 19. The method as recited in claim 18, wherein the action ofcalculating a top level control parameter further comprises calculatingthe top level control parameter based on the combination and a pluralityof previous top level control parameters.
 20. The method as recited inclaim 18, wherein the action of calculating a top level controlparameter further comprises calculating the top level control parameterbased on the combination, a plurality of previous top level controlparameters, and at least one weighting coefficient for each of thecombination and the plurality of previous top level control parameters.21. The method as recited in claim 20, wherein the at least oneweighting coefficient for each of the combination and the plurality ofprevious top level control parameters may be selected so as to control aspeed at which a data stream bit rate is changed.
 22. The method asrecited in claim 1, further comprising: forwarding a data stream asmodified by the top level control parameter.
 23. The method as recitedin claim 22, wherein the action of forwarding a data stream comprisestransmitting the data stream over a network.
 24. The method as recitedin claim 22, wherein the action of forwarding a data stream compriseswriting the data stream to memory storage.
 25. The method as recited inclaim 1, wherein the method is performed by a headend of atelevision-based entertainment system.
 26. The method as recited inclaim 1, wherein the method is performed by a client device of atelevision-based entertainment system.
 27. One or moreelectronically-accessible storage media comprisingelectronically-executable instructions that, when executed by at leastone processor, direct an electronic apparatus to perform the method asrecited in claim
 1. 28. An apparatus, comprising: a time and bitcountmonitor, the time and bitcount monitor adapted to monitor a current timeand a current bitcount in each time window of a plurality of timewindows, each time window of the plurality of time windows overlappingeach other time window of the plurality of time windows; a window levelmodifier generator, the window level modifier generator receiving thecurrent time and the current bitcount for each time window from the timeand bitcount monitor, the window level modifier generator adapted togenerate a window level modifier for each time window based on thecurrent time and the current bitcount for each respective time window; awindow level control parameter determiner, the window level controlparameter determiner receiving the window level modifier for each timewindow from the window level modifier generator, the window levelcontrol parameter determiner adapted to determine a new window levelcontrol parameter for each time window based on the window levelmodifier for each respective time window; a window level controlparameter combiner, the window level control parameter combinerreceiving the new window level control parameter for each time windowfrom the window level control parameter determiner, the window levelcontrol parameter combiner adapted to combine the new window levelcontrol parameter for each respective time window of the plurality oftime windows to produce a combined window level control parameter; a toplevel control parameter history storage, the top level control parameterhistory storage storing a plurality of previous top level controlparameters; a top level control parameter calculator1 the top levelcontrol parameter calculator receiving the plurality of previous toplevel control parameters from the top level control parameter historystorage and the combined window level control parameter from the windowlevel control parameter combiner, the top level control parametercalculator adapted to calculate a top level control parameter based onthe combined window level control parameter and the plurality ofprevious top level control; and wherein the window level controlparameter combiner is further adapted to combine the new window levelcontrol parameters for each respective time window of the plurality oftime windows using an average of the new window level control parametersfor each respective time window of the plurality of time windows. 29.The apparatus as recited in claim 28, wherein the apparatus comprises adynamic rate control unit.
 30. The apparatus as recited in claim 28,wherein the apparatus comprises a headend of a television-basedentertainment environment.
 31. The apparatus as recited in claim 28,wherein the apparatus comprises a dent device of a television-basedentertainment environment.
 32. The apparatus as recited in claim 31,wherein the apparatus further comprises at least one of a local networkoutput or a memory storage.
 33. The apparatus as recited in claim 32,wherein the apparatus is adapted to forward a data stream that ismodified by the top level control parameter to at least one of the localnetwork output or the memory storage.
 34. The apparatus as recited inclaim 28, wherein the new window level control parameter comprises atleast one of a quantization scale or a quantization matrix of a MovingPictures Expert Group (MPEG)-compliant coding/compressing technique. 35.The apparatus as recited in claim 28, further comprisingcomputer-accessible memory; wherein the time and bitcount monitor, thewindow level modifier generator, the window level control parameterdeterminer, the window level control parameter combiner, and the toplevel control parameter calculator are comprised at least partially ofcomputer-executable instructions that are stored on thecomputer-accessible memory.
 36. The apparatus as recited in claim 28,wherein the time and bitcount monitor, the window level modifiergenerator, the window level control parameter determiner, the windowlevel control parameter combiner, and the top level control parametercalculator are comprised at least partially of at least one discreteintegrated circuit.
 37. The apparatus as recited in claim 28, whereinthe time and bitcount monitor is adapted to monitor the current time andthe current bitcount in each time window of the plurality of timewindows in conjunction with monitoring an absolute time and a totalbitcount accumulation that are associated with a data stream.
 38. Theapparatus as recited in claim 28, wherein the window level modifiergenerator is further adapted to generate the window level modifier foreach time window relative to a time slot length and a target bitcountaccumulation associated with each respective time window.
 39. Theapparatus as recited in claim 28, wherein the window level controlparameter determiner is further adapted to determine the new windowlevel control parameter based on at least one of a sum or a productdetermined responsive to the window level modifier and a previous windowlevel control parameter for each respective time window.
 40. Anapparatus, comprising: a time and bitcount monitor, the time andbitcount monitor adapted to monitor a current time and a currentbitcount in each time window of a plurality of time windows, each timewindow of the plurality of time windows overlapping each other timewindow of the plurality of time windows; a window level modifiergenerator, the window level modifier generator receiving the currenttime and the current bitcount for each time window from the time andbitcount monitor, the window level modifier generator adapted togenerate a window level modifier for each time window based on thecurrent time and the current bitcount for each respective time window; awindow level control parameter determiner, the window level controlparameter determiner receiving the window level modifier for each timewindow from the window level modifier generator, the window levelcontrol parameter determiner adapted to determine a new window levelcontrol parameter for each time window based on the window levelmodifier for each respective time window; a window level controlparameter combiner, the window level control parameter combinerreceiving the new window level control parameter for each time windowfrom the window level control parameter determiner, the window levelcontrol parameter combiner adapted to combine the new window levelcontrol parameter for each respective time window of the plurality oftime windows to produce a combined window level control parameter; a toplevel control parameter history storage, the top level control parameterhistory storage storing a plurality of previous top level controlparameters; and a top level control parameter calculator, the top levelcontrol parameter calculator receiving the plurality of previous toplevel control parameters from the top level control parameter historystorage and the combined window level control parameter from the windowlevel control parameter combiner, the top level control parametercalculator adapted to calculate a top level control parameter based onthe combined window level control parameter and the plurality ofprevious top level control parameters; wherein the top level controlparameter calculator is further adapted to calculate the top levelcontrol parameter responsive to an autoregressive model in which thecombined window level control parameter is weighted versus the pluralityof previous top level control parameters.
 41. A client device for atelevision-based entertainment system, the client device comprising: oneor more processors; and one or more memories in operative communicationwith the one or more processors, the one or more memories storingprocess or executable instructions that, when executed, cause the one ormore processors to perform actions comprising: monitoring a currentbitcount of an associated data stream in each time window of a pluralityof time windows, each time window of the plurality of time windowsoverlapping at least one other time window of the plurality of timewindows; generating a window level modifier for each time window basedon the respective current bitcount for each time window and a respectivecurrent time for each time window that corresponds to the respectivecurrent bitcount; determining a window level control parameter for eachtime window based on the respective window level modifier for each timewindow; combining each window level control parameter for each timewindow of the plurality of time windows to produce a combined windowlevel control parameter, wherein combining the new window level controlparameters for each respective time window of the plurality of timewindows uses an average of the determined window level controlparameters for each respective time window of the plurality of timewindows; and modifying a quantization of the data stream based on thecombined window level control parameter.
 42. The client device asrecited in claim 41, wherein the client device comprises a set-top box.43. The client device as recited in claim 41, further comprising: amemory storage in operative communication with the one or moreprocessors; wherein the processor-executable instructions that arestored by the one or more memories cause, when executed, the one or moreprocessors to perform actions further comprising: forwarding the datastream to the memory storage for storage thereat.
 44. The client deviceas recited in claim 41, further comprising: a local output component inoperative communication with the one or more processors; wherein theprocessor-executable instructions that are stored by the one or morememories cause, when executed, the one or more processors to performactions further comprising: forwarding the data stream to the localoutput component for outputting therefrom over a local network.
 45. Theclient device as recited in claim 41, wherein the action of modifying aquantization of the data stream based on the combined window levelcontrol parameter comprises the action of modifying the quantization ofthe data stream based on the combined window level control parameter andat least one previous top level control parameter.
 46. The client deviceas recited in claim 41, wherein the associated data stream of themonitoring action is already encoded and the data stream of themodifying action is transcoded.
 47. The client device as recited inclaim 41, wherein the associated data stream of the monitoring action isnot encoded and the data stream of the modifying action is encoded. 48.A method for providing real-time rate control, comprising: tracking acurrent bitcount in a time window of a plurality of time windows; notinga current time in the time window; generating a window level modifierbased on the current time and the current bitcount in the time window;determining a new window level control parameter for the time windowbased on the window level modifier; repeating the actions of tracking,noting, generating, and determining for each other time window of theplurality of time windows to produce a plurality of new window levelcontrol parameters; combining the plurality of new window level controlparameters to produce a combined window level control parameter;calculating a top level control parameter based on the new window levelcontrol parameter and the plurality of new window level controlparameters, wherein the top level control parameter is calculatedresponsive to an autoregressive model in which the combined window levelcontrol parameter is weighted versus a plurality of previous top levelcontrol parameters stored in a top level control parameter historystorage; wherein each time window of the plurality of time windowsoverlaps at least one other time window of the plurality of timewindows.